(21/21) 163 - Errorlist Patch

instead of hardcoding English phrases like "Select All", we use jEdit.getProperty("common.selectAll")
Not sure if we need a "select" also... but anyway, you can
see other strings that are already translated in jEdit_en.props.
You've already added other strings to Errorlist.props, so you know how to do that already.

Also, you added a typo the the ErrorList docs on line 90.
Please address those 2 issues and re-submit?

Here is a corrected version, let me know of there are any other comments

errorlist.v2.patch (10.4Kio)

ok i ran it. I am missing the "copy selected errors to clipboard" in the popup. It should be in the context menu also.
I don't see the point of "select" since left-mouse button selects it already.

Not sure if we are talking at cross purposes here.

There are 2 entries in the popup menu, "Select" and "Select All" right-clicking an error and picking "Select" copies that error to the clipboard, picking "Select All" copies all the visible errors to the clipboard (so if you have warnings toggled off, for example, then they won't be copied).

I can change the text of the popup menu to make this a bit more obvious if that helps.

Both these options should be available on the context menu as well, if they're not then I'll have a look tonight to see why.

Also I haven't changed the i18n files as I didn't trust Google translate or Babelfish not to give me a translation that would look weird or unintentionally funny to a native speaker.

It turns out your "select" context actions don't change the selection of the treeview either. So they are named incorrectly.
If your "select" copies to clipboard, rename it to "copy to clipboard".
If "select all" copies all to clipboard, rename it to "copy all (errors|warnings)? to clipboard".
Introduce new strings in Errorlist.props and don't worry about translations.

you can jEdit.getProperty("hypersearch-results.copy-to-clipboard") for an already translated "Copy to Clipboard" string from jEdit core

Right I think that covers it, let me know if you see anything else

errorlist.v3.patch (10.5Kio)

Testing the copy to clipboard, I can see the error messages in the copied/pasted text, but I can't see the filenames (tree node names) that the error messages came from.
Can you please fix that too?

Fixed as requested

errorlist.v4.patch (11.0Kio)

Thanks! It's almost there. One more thing I noticed was that the line number is missing from the error message - there is a character # but no line#. I think after that is fixed, it should be ready to go!

Hi,

This is the latest patch (hopefully the last), I've standardised the display to be of the format

line no:start offset:error message

across all of the methods of selecting the text

errorlist.v5.patch (12.6Kio)

The output format in the errorlist window has changed. There seems to be an extra number in the output lines that was not there before. For example, if I "cat" the below file in the console window:
$errorlist> cat asdf.txt
customer.cc:4:21: fatal error: utility.h: No such file or directory
#include "utility.h"
^
customer.cc:5:23: fatal error: utility.h: No such file or directory
#include "utility.h"
compilation terminated.
Process cat exited with code 0
$errorlist>
Then I go to the errorlist window and copy all errors, I see this:
/home/ezust/workspace/jedit/plugins/ErrorList/customer.cc
4:1:21: fatal error: utility.h: No such file or directory

5:1:23: fatal error: utility.h: No such file or directory


Not sure what the :1: came from inbetween the 4 and 21 but it wasn't there last time.

*snip*
However, "copy to clipboard" does nothing.

repasting again as the forum seems to have swallowed my original reply

That's funny I don't see that, can you walk me through the way that you get this.

What I do is:

1) Generate the error (in this case using the XML plugin)
2) Click and highlight the error in question
3) Right Click select "copy to clipboard" (or Plugins->ErrorList->Copy Selected Error to Clipboard)

When I paste out I get something like

/home/timb/crap.xml
2:1:The element type "dd" must be terminated by the matching end-tag "</dd>".

Where the first number is the line and the second is the character offset

*Extra character on copy all*

Not sure I understand the bit about the console, but we can take that offline.

Again I don't see what you are seeing, this is what I get from the copy all to clipboard

/home/timb/crap.xml
2:1:The element type "dd" must be terminated by the matching end-tag "</dd>".
2:5:Misspelled word: ffff

First character line number, the second the offet.

I am wondering if this might be because the plugin you are using to generate this error implements it's own error source, can you ping me the plugin that you are using, and possibly the file that is generating the error and I'll have a play.

Attaching a file called "errors.txt" which contains the output of gcc, when it is compiling a program with errors. I just "cat" the file from console to see errors in errorlist . It's a bit easier to test the error parsing abilities of the plugin.

errors.txt (228B)

Apologies. "Copy to Clipboard" does work if something is selected, but if I am over an area of ErrorList while there is no selection, I can still invoke the action and then it does nothing.
I guess I was just confused.
Perhaps if there is no selection, that action should not appear in the context menu.
BUG: If there is a multiple selection, "copy to clipboard" only copies the first selected item.

Additional info, the errors.txt issue where I see extra :1 in the output happens if I am using Console's Generic or Gcc error parsers.
If I use the "gcc" error parser, there is normally no column number at all in the error output, but now I see a :1 for the column number.

This screenshot shows the gcc error parser.

screenshot_041.png (87.5Kio)

This screenshot shows the Generic error parser on errors.txt

screenshot_042.png (90.8Kio)

Thanks I'll have a look at this, sadly work I actually getting paid to do is impinging on my hacking time.

With respect to extra numbering issue, what I suspect is happening, though I haven't been able to prove it yet, is this:

The display on the errorlist tree has been changed to display the line number, the start offset and the error message in the format.

line#:offset#:error message

When you cat the error file in, what may be happening is that the offset is not being correctly parsed into the error message.

This means that in the case of the GCC Parser it is parsing the error message correctly as
"fatal error: utility.h: No such file or directory
#include "utility.h"

But it is taking the line number and position *from the errors.txt file* hence you get 4:1.

For the Generic parser, I think it is taking the line number and position from the errors.txt file , yielding the 4:1, but I think that it is also parsing out the :21 and treating it as the start of the error message.

Hence you get the 4:1 from the line number and offset in the errors.txt and the error message is.

":21 fatal error: utility.h: No such file or directory
#include "utility.h"

But as I say, this is just suspicion, and I haven't been able to prove that out yet.

I see the same problem from the XML plugin - an extra :1 where there was none before.
With XML, there was no column number reported before.
So this is not specific to Console.
I guess your intention is to add a :1 to the places where no column number is available, which is OK with me, but please don't also add it to the error outputs of the others that already have a column number.

Hi,

It's been a while since I've had a chance to have a look at this, I have incorporated a couple of changes, greying out the "copy to clipboard" if there is no item selected and if you select "copy to clipboard" when a filename is selected then it copies all the errors from that file to the clipboard.

However, I have not been able to relicate the error with the extra :1 which you are seeing, so I have added some extra logging.

Can you apply this patch (errorlist.v6.patch) locally and run through to get the error again, then post the activity log so I can have a look ?

Thanks

errorlist.v6.patch (14.6Kio)

Hi Alan,

Have you had a chance to look at this at all ?

Thanks

Here is the activity log from using errorlist.
You can see in this line:
8:04:59 AM [AWT-EventQueue-0] [debug] EditBus: ErrorSourceUpdate[source=null,what=ERROR_ADDED,errorSource=errorlist.DefaultErrorSource[error parsing],error=customer.cc:4:1:21: fatal error: utility.h: No such file or directory
the extra :1 between 4 and 21.

errorlist.log (56.4Kio)

Ok this looks like an issue with the way that the error file that you are usng is being parsed out and passed to the ErrorList. The line number is passed correctly, but the start offset is taken from the file that you are cat-ing (hence the 1), what looks like the line number was actually parsed out and put in the front of the error message, hence it looks like there is an extra line number in the display.

This begs the question, is this a valid condition that should be handled by the error list plugin, or just a side effect of the way that the testing is being run? As trying to code round this issue might get a little flakey.

Are you seeing the same issue when not feeding the errors by cat-ing an error file? If so can you post the log file ?

Logging in the code

Log.log(Log.DEBUG,ErrorList.class,"Adding Error Line#" + (error.getLineNumber()+1)
+ " Start#" + (error.getStartOffset()+1) + " Error Message:" + error.getErrorMessage());

Log message

8:04:59 AM [AWT-EventQueue-0] [debug] ErrorList: Adding Error Line#4 Start#1 Error Message:21: fatal error: utility.h: No such file or directory

The XML plugin also reports an extra :1 where there wasn't one before.
And I see a different issue if I use a different error parser. But in all cases there is an extra :1.

errorlist.log (41.5Kio)

Hi,

looking at the log attached I can't see the logging messages that I would expect to see from the ErrorList plugin, which is slightly confusing.

Can you post the XML file that you are using to generate the errors and a screen shot please.

One suggestion I have is that we drop this message formatting from the current patch for now, as the original change request was to add select/select all functionality to the error list plugin and we have gotten somewhat side tracked by this formatting issue which wasn't part of the original CR.

That means that we can roll the requested enhancement into the next release, and I'll raise another CR to cover the formatting issue.

What do you think ?

it happens with any xml file that has an error in it.
yes, I agree, separating the formatting changes from the actual feature request would be a great idea.
Then we can test the other patch by itself and more easily figure out what is going on. sorry I didn't have time to debug it myself, I've been busy.

OK, I have reverted the formatting changes so it should be performing as it did originally, i.e. the message is built from the line number and the error message.

errorlist.v7.patch (13.9Kio)